Database systems are used for a variety of applications. FIG. 1 depicts a portion of a conventional database system 10 used by a client 20. The database system includes a processor 12 having a local memory 14 and a storage subsystem 15, typically disks. The database system 10 typically stores data in the form of tables, such as the table 16. The table 16 can be considered to have one or more pages 17 and be organized in columns 18 and rows 19.
FIG. 2 depicts a conventional method 30 for performing transactions using the database system 10. Transactions are typically provided to the database system 10 in the form of statements, for example in structured query language (SQL). Transactions may include one or more statements for performing a variety of operations including but not limited to additions, subtractions, other changes or updates to the information stored in the table 16, requests for information, and other operations. The conventional method 30 typically commences after a transaction, or statement, has been provided to the database system 10 for processing.
Locks are obtained on portions of the table 16 for the transaction, via step 32. Typically, a row lock is obtained for a row 19, in step 32. However, in other conventional methods, the granularity of the lock may change. For example, instead of row locking, page or table locking can be performed. The transaction is processed to completion, via step 34. Thus, step 34 includes performing any commit statement necessary to write information to the disks in the storage subsystem 15. The locks, such as the row locks, are released, via step 38. Processing of another transaction may be performed, via step 38. Step 38 may thus repeat steps 32-36 for another transaction.
Although the conventional method 30 functions, one of ordinary skill in the art will readily recognize that in many cases, it is inefficient. Many database systems 10 manage large amounts of data and undergo a large number of operations to a particular row 19 or column 18 in the table 16. For example, in banking, inventory tracking, credit card, or reward systems (e.g. frequent flier) applications, only one or two columns 18 in the table 16 are frequently changed. For example, suppose that the table 16 relates to a banks credit card or other accounts. The table 16 may thus have columns 18 for account holders' names, account holders' addresses, the account type, and the balance of the account. The columns 18 relating to the account holder's name and address change infrequently. In contrast, columns 18 relating to the balance in the account, or the stock of a particular item on hand for an inventory table, change frequently. For a bank having many customers, the column relating to the account balance may be subject to numerous transactions hourly. Moreover, many of the transactions that change such columns share common characteristics. Such transactions are not tied to a specific value of the data in the column. In particular, addition and subtraction operations, otherwise known as credit and debit operations, do not depend upon the balance in the column for which the addition or subtraction operations are used. When such operations are completed using the conventional method 30, each addition and subtraction must wait for the release of the locks in step 36 prior to beginning processing. Stated differently, statements in transactions that attempt to access the same row and column that are already accessed by statements in another transaction must wait for the lock to be released prior to commencing. Consequently, performing such operations on a table 16 may take a significant amount of time to complete.
Accordingly, what is needed is a method and system for more efficiently performing transactions such as addition/subtraction (or credit/debit) transactions in a database system. The present invention addresses such a need.